Radio Access Networks (RANs) in cellular telecommunication systems may include base stations (e.g., NodeBs or eNodeBs) utilizing different Radio Access Technologies (RATs). For example, most of the area covered by a RAN may utilize 3G NodeBs in a Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (UTRAN), while pockets or islands within the coverage area utilize eNodeBs in a Long Term Evolution (LTE) access network. Such networks can cause problems implementing a Mobile Robustness Optimization (MRO) function when a User Equipment (UE) moves between different RATs.
One of the goals of a consistent MRO function is to make failure reports available in the nodes where the failure originated, assuming these nodes are the ones responsible for performing corrective action. In various scenarios, the UE may experience an RLF while moving between LTE eNodeBs, or when performing an Inter-RAT (IRAT) handover between an LTE eNodeB and a UTRAN NodeB.
FIG. 1 is a sequence diagram illustrating an existing solution for IRAT MRO. As illustrated, a UE operating in eNodeB_1 experiences an RLF and then reconnects for a period of time in 3G Cell_1. Subsequently, the UE is handed over to LTE again and connects to eNodeB_2. In this solution, as adopted by the Third Generation Partnership Project (3GPP) in LTE Release 11, the UE stores link failure information (formatted in a RLF Report as defined in TS36.331) while operating outside of the LTE area (e.g., in 3G Cell_1), and sends the RLF Report with the failure information to the first eNodeB it reconnects to when it returns to LTE (which may not be the eNodeB where the failure occurred). The serving eNodeB receiving the RLF report from the UE (e.g., eNodeB_2) should forward the failure information to the original eNodeB where the failure occurred (e.g., eNodeB_1) via an X2AP RLF Indication message as defined in TS36.423.
FIG. 2 is a sequence diagram illustrating a problem with the existing solution for IRAT MRO of FIG. 1. Forwarding of the failure information to the original eNodeB where the failure occurred is only ensured if the eNodeB receiving the RLF Report has an X2 connection with the original eNodeB where the failure occurred. This is because the RLF Report is forwarded only via the X2AP RLF Indication message as defined in TS36.423. If the X2 connection does not exist, these reports are currently discarded by the eNodeB receiving the RLF report from the UE.
As noted above, initial LTE deployments may consist of coverage “islands” within extended areas of UTRAN coverage. UEs only send RLF Reports to LTE eNodeBs. Thus, when a UE is connected to an eNodeB belonging to an LTE island and suffers an RLF while handing over to a UTRAN NodeB, the UE will only report the failure when the UE subsequently reconnects to an LTE eNodeB. The eNodeB that receives the RLF Report from the UE may be in another LTE island distant from the eNodeB where the failure occurred. Since direct handovers between eNodeB's belonging to these distant islands are unlikely or impossible, there will be no X2 connection between the eNodeB that receives the RLF Report from the UE and the original eNodeB where the failure occurred. Consequently, the eNodeB that receives the RLF Report from the UE will discard the report. Thus, the failure information will never be reported, and the performance of the Inter-RAT MRO solution may be severely affected. This implies that a reliable root cause analysis of the failure cannot be carried out by the failure eNodeB and the failure cannot be corrected.
In the present disclosure, the problem addressed is that of ensuring a robust MRO solution by making failure reports available in the node where the failure originated, especially in scenarios where there is no direct connection between the node experiencing the failure and the newly serving node. These scenarios could be, for example:
Scenario 1) Failure while in LTE or during a handover (HO) to 2G/3G, reconnection at 2G/3G;
Scenario 2) Failure during or after a HO from 2G/3G to LTE and reconnection back at 2G/3G;
Scenario 3) Failure while in 2G/3G or during a HO to LTE, reconnection at LTE; and
Scenario 4) Failure during or after a HO from LTE to 2G/3G and reconnection back at LTE.
In all the scenarios above, it can be observed that a mobility failure may occur while the UE moves from one RAT to another. Thus, after the failure, the UE may camp on, or be served by, a RAT different from the source RAT. Also, after the failure, the UE may connect to a 2G/3G NodeB not supporting RLF Report signaling, i.e., the NodeB does not support parts of the MRO function. This implies that the failure information available at the UE will not be reported to the LTE network before the UE manages to connect to an eNodeB supporting RLF Reporting signaling. The eNodeB where the UE connects after the failure and where the failure information is eventually reported is likely to be geographically distant from the eNodeB where the failure occurred, and there will probably not be an X2 connection between the two eNodeBs, which prevents forwarding the failure information from one eNodeB to another. The IRAT MRO solution specifies that the RLF Report shall be forwarded from the eNodeB where it was retrieved to the eNodeB where the failure occurred via the X2AP:RLF Indication message.
The above description highlights how the RLF Report stored at the UE may, in several cases of IRAT mobility failure, be lost and never reported to the nodes that could make use of it.
In scenarios with LTE islands within extended areas of UMTS coverage, the current 3GPP solution would require extensive (and perhaps unrealistic) use of the X2 interface between LTE cells in different islands. For this to work, X2 would have to be configured between all eNodeBs at the edge of different coverage islands, which would require unacceptably high memory consumption and a waste of node resources.
Other solutions for this scenario have been proposed in R3-122081 where it is proposed to introduce a method for forwarding the RLF report container over the S1 interface to the core network (i.e., the Mobility Management Entity (MME)) for cases where X2 is not set up. In one solution, an extension of the Self Optimizing Network (SON) Configuration Transfer was proposed. Another solution relies on MME CONFIGURATION TRANSFER and eNB CONFIGURATION TRANSFER extended with a MRO Failure Event Reporting IE.